IBIS Macromodel Task Group Meeting date: 20 December 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Reminder: The meeting on December 27th is cancelled. - Arpad thanked the group for all the effort and accomplishments in 2016. ------------- Review of ARs: - Michael M. to submit the Deterministic Noise Support BIRD draft, with the discussed changes, to the Open Forum. - Done. Submitted as BIRD 188. - Michael M. to submit the Format and Usage Out Clarifications BIRD draft, with the discussed changes, to the Open Forum. - Done. Submitted as BIRD 187. - Arpad to email Vladimir and Fangyi to discuss moving forward with BIRD 166 or their proposal. - Done. (see below) - Walter and Radek to review BIRD 158.3. - Done. Walter noted that he and Radek had discussed it and come to a good agreement on how to proceed. Walter said he had prepared an updated BIRD that we could review. Radek noted that they agreed in principle, but would also be interested in getting Fangyi's input. - Arpad to produce some slides on converting between BIRD 158.3 syntax and the equivalent [External Model] (BIRD 160) syntax. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob: [sharing [Local Reference] keyword draft 6] - Radek and I met yesterday. - [Local Reference] keyword explicitly provides attachments to the various capacitances, unless some other Sub-Param like C_comp_pullup overrides it. - We discussed terminology and stuck with "node" here, although "terminal" is used in BIRD 181. - Default value is zero if not given. - The associated Local_ref node defines a common reference. - Certain blocks of text may be positioned elsewhere and referred to by other reference keywords. Another BIRD could potentially add references to this new text from other reference keyword sections. - We have the "node collapse" rule, where if two [* Reference] keywords have the same voltage values for all three corner cases then they can be considered one rail. - Arpad: I might prefer "merged nodes" or "shorted nodes" to "collapsed nodes." - Bob: I like merged nodes. - Radek: Agreed. - Bob: However, we also might have to deal with a case where the [* Reference] voltages are the same, but due to routing issues you might have separate paths and unique nodes. - If the [Pin Mapping] specifies different bus labels for two *_ref nodes that would otherwise have been merged, then the nodes are not merged. - Deciding which node would be the local reference node in such a case is something we are considering. - Radek: The point we got stuck on is whether we should allow the case in which all of the [* Reference] keywords have non-zero values. - This would be consistent with the current spec. - This case is probably not practical. - It could perhaps be handled with a parser warning. - The model maker may have reasons for doing it. - If the Local_ref we are adding here is not the same as one of the other *_ref nodes, then we have that same situation. - We may want to disallow it, but we don't have a solution at this point. - Walter: As a solution, could we say that if this situation arises, then power- aware simulations will require a ground based reference system, as was proposed by Scott McMorrow? - There's a legal way to do that with a ground based reference system. - It's only an issue if you want to do power-aware simulations. - Radek: Agreed, if you aren't concerned with power-aware simulations then it's a no brainer and you bias the model as given in the [* Reference] keywords and everything is fine. - Bob: We can add something like Walter's statement. - Radek: That statement effectively uses the GND (local reference) node as part of the simulation model. - The [Pin Reference] solution suggested in another proposal is the solution for the power-aware case. - Bob: That might be where we aren't in agreement. - I don't think we should need [Pin Reference]. - This should be sufficient without it. - We can avoid this pathological case where the Local_ref is different than all the other *_ref nodes. - Radek: The Local_ref is intended to provide a means for connecting the C_comp, C_pin, C Package matrices. This is not really provided by the current spec. - Radek: That's a good summary of where we are, but we are not done. BIRD 166: - Arpad: [sharing Fangyi's email response regarding proceeding with BIRD 166] - Arpad: Fangyi's email arrived recently. He states that BIRD 166 really only covers one special case, and it does not work when cross talk is present. He doesn't think moving forward with BIRD 166 by itself will be sufficient. Fangyi hopes to work on his proposal and have an update in January. IBIS 6.2 discussion (what is needed to complete it?): - Michael M: [sharing BIRD 187.1] - This new update to BIRD 187 might be relevant to this topic. - At the last Open Forum and ATM meetings, several people noted that there was some additional text related to Usage Out parameters that occurred later on in the specification, beyond the scope of the text originally considered in BIRD 187. - This new 187.1 adds a lot of additional text just to explicitly state and clarify what is in the specification without changing it. - There are some small enhancements to Increment, Step, and Corner rules. - Arpad: I ask the entire group to take it as an AR to review 187.1. BIRD 158 syntax vs. "official" BIRD 160 syntax. - Arpad: [Sharing 'How to write BIRD 158 Models with "official" IBIS syntax'] - [Slides 1, 2, 3] - Introduction and background on BIRD 158 vs. BIRD 160. - [Slide 4] (see below) - [Slide 5] BIRD 158 Tx .ami file excerpt and diagram - Note: "Model Specific" would become "Reserved" if BIRD 158 were approved. - Example uses Tx_V, Tx_R, Tstonefile parameters. - [Slides 6-7] The same Tx model with BIRD 160 syntax - IBIS_ISS language. - ISS_wrapper.inc contains subcircuits. - Unique subcircuit for each corner case. - Three D_to_A converters for the corner cases of the Non-Inverting Pin. - Three D_to_A converters for the corner cases of the Inverting Pin. - Note that the [Ramp] keyword and trise/tfall contain identical slew rates. - RefNode in the subcircuit could be the reference node for the D_to_As. - This is just one example of a way to implement it. There are others. Multiple individual subcircuits could probably be reduced to one subcircuit if parameter passing were used. - Discussion: Bob asked about the RefNode usage. Arpad said that the s4p has five terminals when a common reference is used. Radek commented that the [External Model]'s A_gnd port could serve this purpose. Bob noted that BIRD 158 implicitly uses node 0 for this. Radek also noted that BIRD 158 would dispense with the slew rate from the D_to_A or [Ramp] and assume everything is in the S-parameter file and the step used to calculate the impulse response should be "ideal". - [Slide 8] BIRD 158 Rx .ami file excerpt and diagram - Example uses Tstonefile and Rx_R. - [Slides 9-10] The same Rx model with BIRD 160 syntax - Again one subcircuit for each corner. - Since we were just discussing referencing, note that the R is just connected to node 0 in the subcircuit. - This model uses an A_to_D. - The IBIS spec allows you to connect the A_to_D so it probes at the pad or the core side. In this example we are looking at the core side, so we see the results after passing through the S-parameter block. - [Slide 4] Comparing BIRD 158 and 160. - BIRD 158 places the Tstonefile parameter in the .ami file. - It is only available to AMI simulations. - That may provide performance advantages. For example, it might eliminate the need for a time domain channel characterization. - BIRD 160 uses [External Model] to wrap the S-parameters. - It is generally available to any IBIS simulation. - Channel characterization would normally be done in time domain. - This has performance and possibly accuracy issues. - However, an EDA tool could detect when the Tx and Rx [External Model]s were each simply wrappers for an .s4p, and in that case the EDA tool could apply BIRD 158 simulation flow automatically. For example, staying in frequency domain for channel characterization if possible. - Discussion: Walter noted that while the last statement (the EDA tool could detect when External Models were merely wrapping .s4p files) was possible in principle, in practice it was onerous. The tool would have to parse through both the [External Model] sections of the models and the included subcircuits, all in the hope of discovering that it was as simple as the special case shortcut provided by BIRD 158. Arpad noted that he sometimes liked to run only the analog portions of an AMI model as a basic startup step. BIRD 158 would push this processing into the AMI engine. Walter said that BIRD 158 defined Usage Info parameters that were generally available to the EDA tool for any simulation. Since none of the processing of the interconnect model was pushed down into the AMI model (Usage In parameters), there was no restriction on how the EDA tool could make use of the information in the BIRD 158 parameters. Radek noted that it was really a question of what the model maker wanted to do. Did they want the BIRD 158 shortcut, or the perhaps more general BIRD 160. If both approaches were available to the model makers, then there would be no need to translate between the two. Radek noted that the BIRD 160 approach might contain a non-linear representation of the IBIS buffer, and the AMI simulation only extracts some linear representation of it for use in AMI. Bob noted that it could be done either way. If the S-parameter data required a slew rate limited input, then the legacy approach with [Ramp] could be used. If the S-parameter data contained the buffer characterization, then the BIRD 158 ideal step approach should be used. - Walter [referring back to slide 5 - BIRD 158 AMI Tx] - In my current BIRD 158.4 I'm still using this picture (with two distinct voltage sources). - I think a simpler and more effective picture would be to consider a pure differential source between the two pins, without a reference to local ground. - That would eliminate the local ground from the Tx. I'm not sure if it's easy to eliminate it from the receiver. - Originally I had two separate voltage values, Tx_Voh and Tx_Vol, for the sources on each line to try to handle common mode. But that is what caused some concern for Radek. - Arpad: Going to differential would also simplify my D_to_A converter, and port1 and port2 of the D_to_A could just be the inverting and non-inverting terminals. We could eliminate the extra steps there for the common reference. - Radek: You do have the reference node for the S-parameters. - This does not have to be GND. It can be a common node on the Tx and Rx sides. - Depending on the data in your S-parameters file, you should not ignore the common mode. The sources and the output should be connected to the same node as the reference node of the S-parameter data. - Arpad/Radek: Yes, we can talk about it further. - Bob: It sounds like we already have a solution with BIRD 160. - Walter: We don't have a good solution for people who want to stay in the frequency domain. - We just described multiple ways of describing these depending on single- ended or differential D_to_A, how you terminate the Touchstone circuit, etc. - For people who are doing frequency domain IR generation, we do not have a very good way of conveying this information to the tool. - Bob/Arpad: Yes, there are pluses and minuses to each. - Walter: There is a common solution. - We could make the BIRD 158 parameters Reserved (approve it). - That provides the shortcut. - You could also implement all those parameters using the BIRD 160 approach, and then we have a solution for both ways. - Bob: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 03 January 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives